1. Field of the Invention
The invention relates to telecommunications switching systems. More particularly, the invention relates to telecommunications call processing logic which is dynamically modifiable without interruption of service.
2. State of the Art
Modern telecommunications switching systems use hardware and software to process calls and provide various telecommunications services. Call processing generally involves at least two segments, the originating call segment and the terminating call segment. These segments refer to the calling party and the called party. In multi-party calls, there may be several segments involved in call processing.
The originating call segment is processed, for example, by setting up the call, granting authorization for the call, collecting and analyzing information, and selecting a route for the call. In the case of wireless cellular telecommunications, the originating call segment may also be processed by selecting a frequency, measuring signal strength, initiating a handoff, etc.
The terminating call segment is processed, for example, by presenting the call, finding resources, accepting the call, and answering the call. In the case of wireless cellular telecommunications, the terminating call segment may also be processed by selecting a frequency, measuring signal strength, initiating a handoff, etc.
In both the originating and terminating call segments, calls are further processed by detecting busy networks and busy terminals, by detecting disconnects and failed authorizations, and by detecting no answers, for example.
State of the art software used in call processing is "hard coded" in the host processor of a digital telecommunications switch. When a call segment is initiated, a particular software routine is called and is run from start to end. As with all software systems, and in particular with telecommunications software systems, frequent system updates need to be made. These updates are used to effect new features, to change the configuration of a switch, to improve efficiency, or to eliminate bugs, for example. One of the difficulties in updating telecommunications software is that the software must continue to run so long as the switch is in operation. Therefore, in order to modify the software, the switch must be taken out of service while the system update is performed. This is problematic for two reasons. Service is diminished during the update process and calls will often be interrupted when the switch is taken out of service. Moreover, if the system update needs to be de-bugged, the switch must be taken out of service again resulting in further diminished service capacity and additional call interruptions.
One partial solution to the problems of software system updates is to use redundant switch hardware and software. In these systems, a backup switch system is updated with new software without interrupting the main switch hardware and software. After the backup system is updated, service is transferred from the main switch system to the backup system and the main switch is updated. This solution avoids much of the problem relating to diminished service capacity, but it does not solve the problem of interrupted calls. During the transfer from the main switch to the backup switch, there is a short period of service interruption. During the transfer, transient calls (calls which are in the process of being connected) on the main switch will be dropped. This partial solution is relatively expensive in that almost every hardware component of the switch must be duplicated. In addition, the software used to effect a transfer of service from the main switch to the backup and vice versa is complex.
Another, more sophisticated approach to solving the problems associated with system updates is described in the Bellcore Advanced Intelligent Networks (AIN) specification. The AIN specification modularizes system software so that new features can be added without interruption of service. Prior art FIG. 1 shows a schematic diagram of the AIN specification. The system software includes a main call processing module 10 which is structured as a finite state machine having well defined points-in-call (PICs) 12a, 12b, . . . , 12n, each of which is associated with one or more trigger detection points (TDPs) 14a, 14b, . . . , 14n where the state machine sends a query to an external service logic program (SLP) 16a, 16b, . . . , 16n to receive instructions for the further processing of the call. SLPs may reside locally or remotely and may be modified without interrupting the main call processing module 10. For example, the first PIC 12a in an originating call module may get the number dialed and the first TDP 14a will parse the number to determine if it contains a special feature such as being an "800" number or a "900" number. If the number is an "800" number, for example, an SLP 16a for "800" number service is invoked. The next PIC 12b may be used to route the call to an appropriate trunk, etc.
A significant drawback of the AIN specification is that the main call processing module 10 must be painstakingly designed in order to anticipate the addition of every possible SLP and provide appropriate TDPs. Thus far, the AIN specification has been only partially implemented. For example, AIN specification version 0.1 has been implemented and version 0.2 has been partially implemented. These implemented specifications provide relatively limited functionality. An all-encompassing AIN specification version 1.0 is being designed, but it will require years of development and testing before the entire specification can be realized. In its present state, AIN version 1.0 requires additional capabilities from an underlying communications protocol (the TCAP layer of the SS7 protocol stack) which is not supported by any of today's standards. For example, the message lengths required by AIN 1.0 exceed the maximum message length permitted by the ANSI TCAP protocol in use today. Moreover, the AIN specification is not designed to facilitate incremental development of new features, but rather to accommodate a large number of predefined features (SLPs). In addition, the AIN specification does not provide any way to directly modify the main call processing module 10 without interrupting service. Nevertheless, AIN specifications 0.1 and 0.2 have received widespread support and most switch systems sold today support the AIN specifications 0.1 and 0.2 (as well as other specifications).